I'm thinking this object can be extended to handle other related semanticNonNull functionalities e.g. @catch?
(I'm not entirely sure how it'd work yet, but I imagine there could be options we turn on/off here 😅 )

I see @catch as mainly orthogonal to @semanticNonNull. Sure they make a lot of sense together but you can have an error handling client that uses @catch(to: RESULT) or @catch(to: THROW) without semantic nullability on the server.

That client will not get the semantic nullability information but could still use @catch to modify the shape of the generated code.

I would keep it simple/yagni with just a plain Boolean option:

semanticNonNull?: boolean

If really you want to bundle nullability options together, maybe something like so:

nullability?: {
  semanticNonNull: boolean;
  catch: boolean;
}

I'm a bit unsure about this:

• schema is a DocumentNode
• shemaAst is a GraphQLSchema
• We can forcefully override schema with schemaAst ... and it works 🤔

Maybe when loading schema in each generates block, we do a check? That's my best guess though, and if anyone has more context, please let me know!

EDIT: Looks like it's somewhere here 👀

Maybe what you want here is this?

Just guessing from the types you mention, I'm not familiar with this codebase.

Perhaps, and this is just a suggestion, rename this to "semantic nullability" as a more generic term. If we were to accept a solution that used a document directive to enable the syntax, this is the likely name that we would use for that directive, and it doesn't tie the solution to one specific implementation. (GraphQL-SOCK can be updated to work with other solutions without any effort on your part.)

I personally would rename the schema variable to inputSchema so that schema, the variable you'd use by default, is the correct variable to use:

(This would also mean no other changes were needed in the function.)

Maybe what you want here is this?

Just guessing from the types you mention, I'm not familiar with this codebase.

I like semanticNonNull. This option is part of the overall solution but doesn't solve all of semantic nullability. It's very specific about the codegen and the support of @semanticNonNull but doesn't touch the runtime.

Counter proposal:

By using graphql-sock this supports not only @semanticNonNull the directive but all the proposed solutions (assuming GraphQL.js support) to the semantic nullability RFC. Theoretically this should already work just fine with the * syntax when using graphql@canary-pr-4192 for example (I've not tested it though). If we were to come up with an alternative solution (e.g. GraphQLStrictNonNull to represent the old "kills parent on exception" style of non-null) then "semantic nullability" would still cover this solution, but "semanticNonNull" would not.

I'd support renaming the option to simply nullability though, as you proposed separately.

I see @catch as mainly orthogonal to @semanticNonNull. Sure they make a lot of sense together but you can have an error handling client that uses @catch(to: RESULT) or @catch(to: THROW) without semantic nullability on the server.

That client will not get the semantic nullability information but could still use @catch to modify the shape of the generated code.

I would keep it simple/yagni with just a plain Boolean option:

semanticNonNull?: boolean

If really you want to bundle nullability options together, maybe something like so:

nullability?: {
  semanticNonNull: boolean;
  catch: boolean;
}

I like semanticNonNull. This option is part of the overall solution but doesn't solve all of semantic nullability. It's very specific about the codegen and the support of @semanticNonNull but doesn't touch the runtime.

Counter proposal: